1. Field of the Invention
The invention relates to the field of EDA design, and more particularly to a system and method for efficiently storing precharacterization data and accurately generating model output data from that precharacterization data.
2. Related Art
An electronic design automation (EDA) system is a computer software system used for designing integrated circuit (IC) devices. The EDA system typically receives one or more high level behavioral descriptions of an IC device (e.g., in HDL languages like VHDL, Verilog, etc.) and translates (“synthesizes”) this high-level design language description into netlists of various levels of abstraction. A netlist describes the IC design and is composed of nodes (functional elements) and edges, e.g., connections between nodes. At a higher level of abstraction, a generic netlist is typically produced based on technology independent primitives.
The generic netlist can be translated into a lower level technology-specific netlist based on a technology-specific (characterized) cell library that has gate-specific models for each cell (i.e., a functional element, such as an AND gate, an inverter, or a multiplexer). The models define performance parameters for the cells; e.g., parameters related to the operational behavior of the cells, such as power consumption, output slew, delay, and noise. The netlist and cell library are typically stored in computer readable media within the EDA system and are processed and verified using many well-known techniques.
FIG. 1 shows a simplified representation of an exemplary digital ASIC design flow. At a high level, the process starts with the product idea (step E100) and is realized in an EDA software design process (step E110). When the design is finalized, it can be taped-out (event E140). After tape out, the fabrication process (step E150) and packaging and assembly processes (step E160) occur resulting, ultimately, in finished chips (result E170).
The EDA software design process (step E110) is actually composed of a number of steps E112-E130, shown in linear fashion for simplicity. In an actual ASIC design process, the particular design might have to go back through steps until certain tests are passed. Similarly, in any actual design process, these steps may occur in different orders and combinations. This description is therefore provided by way of context and general explanation rather than as a specific, or recommended, design flow for a particular ASIC.
A brief description of the component steps of the EDA software design process (step E110) will now be provided. During system design (step E112), the designers describe the functionality that they want to implement and can perform what-if planning to refine functionality, check costs, etc. Hardware-software architecture partitioning can occur at this stage. Exemplary EDA software products from Synopsys, Inc. that can be used at this step include Model Architect, Saber, System Studio, and DesignWare® products.
During logic design and functional verification (step E114), the VHDL or Verilog code for modules in the system is written and the design is checked for functional accuracy. More specifically, the design is checked to ensure that it produces the correct outputs. Exemplary EDA software products from Synopsys, Inc. that can be used at this step include VCS, VERA, DesignWare®, Magellan, Formality, ESP and LEDA products.
During synthesis and design for test (step E116), the VHDL/Verilog is translated to a netlist. The netlist can be optimized for the target technology. Additionally, the design and implementation of tests to permit checking of the finished chip occurs. Exemplary EDA software products from Synopsys, Inc. that can be used at this step include Design Compiler®, Physical Compiler, Test Compiler, Power Compiler, FPGA Compiler, Tetramax, and DesignWare® products.
During design planning (step E118), an overall floorplan for the chip is constructed and analyzed for timing and top-level routing. Exemplary EDA software products from Synopsys, Inc. that can be used at this step include Jupiter and Floorplan Compiler products.
During netlist verification (step E120), the netlist is checked for compliance with timing constraints and for correspondence with the VHDL/Verilog source code. Exemplary EDA software products from Synopsys, Inc. that can be used at this step include VCS, VERA, Formality and PrimeTime products.
During physical implementation (step E122), placement (positioning of circuit elements) and routing (connection of the same) is performed. Exemplary EDA software products from Synopsys, Inc. that can be used at this step include the Astro product.
During analysis and extraction (step E124), the circuit function is verified at a transistor level, this in turn permits what-if refinement. Exemplary EDA software products from Synopsys, Inc. that can be used at this step include Star RC/XT, Raphael, and Aurora products.
During physical verification (step E126), various checking functions are performed to ensure correctness for manufacturing, electrical issues, lithographic issues, and circuitry. Exemplary EDA software products from Synopsys, Inc. that can be used at this step include the Hercules product.
During resolution enhancement (step E128), geometric manipulations of the layout are performed to improve manufacturability of the design. Exemplary EDA software products from Synopsys, Inc. that can be used at this step include the iN-Phase, Proteus, and AFGen products.
Finally, during mask data preparation (step E130), the “tape-out” data for production of masks for lithographic use to produce finished chips is performed. Exemplary EDA software products from Synopsys, Inc. that can be used at this step include the CATS® family of products.
As indicated in FIG. 1, timing analyses can be performed at various points along the EDA process, such as during synthesis, design planning, netlist verification, and analysis (as indicated by the bolded chevrons). Timing analyses typically involve the modeling of delays as a signal propagates through a network of cells. The accuracy of the delay calculations controls the quality of the final IC produced using EDA systems.
To perform a timing analysis, the IC design (or a portion of the IC) is defined as a network of drivers and receivers. Cells designated as drivers provide stimuli to the network, and the resulting waveforms are received by the cells designated as receivers. For example, FIG. 2 shows a schematic diagram of a sample driver-receiver network 200 that includes a driver (cell) 210 and a receiver (cell) 230. An input pin 211 of driver 210 receives a driver input signal S_IND and generates a driver output signal S_OUTD at a driver output pin 212. This signal is transmitted across an interconnect element 220 and is received as a receiver input signal S_INR at a receiver input pin 231 of receiver 230 (depicted as an inverter for exemplary purposes). Receiver 230 processes receiver input signal S_INR and generates a receiver output signal S_OUTR at a receiver output pin 232. Note that receiver 230 can also function as a driver for downstream cells, as indicated by load 240 connected to receiver output pin 232.
Conventional driver models represent transistor behavior by indexing the output voltage behavior of the driver by input slew and output capacitance. For example, FIG. 3 shows a conventional driver model 210A for modeling driver cell 210 shown in FIG. 2. Driver model 210A includes a time-dependent voltage source V210A in series with a drive resistor R210A and driver output pin 212A, and an output capacitor C210A coupled between pin 212A and ground. Driver model 210A is sometimes referred to as a “Thevenin model”. Driver model 210A is precharacterized (via SPICE simulations or actual device measurements) by applying a range of driver input signals S_INA (e.g., precharacterization input signals S_INA1 through S_INAP) to input pin 211A across a range of capacitance values for output capacitor C210A (e.g., precharacterization capacitance values C1 through CN). Each input signal S_INA exhibits a particular input slew SI (i.e., the time required for the signal to go from one logic state to the opposite logic state) and a particular input delay time TDI (i.e., the time at which input signal S_INA reaches a threshold level). The resulting driver model output signals S_OUTA (e.g., output signals S_OUTA1 through S_OUTAQ) each exhibit a particular output slew SO and an output delay time TDO. By subtracting the input delay time TDI of an input signal S_INA from the output delay time TDO of the associated output signal S_OUTA, an output delay value DOUT can be determined. The output slew SO and the output delay value DOUT for each of output signals S_OUTA can then be indexed by input slew SI and output capacitances C1 through CN in a precharacterized library cell entry for driver cell 210.
Thus, conventional driver models are generally extracted from libraries of output slew and output delay values. However, as the devices used to instantiate the driver cells in a system continue to shrink, the driver cells formed from those devices begin to exhibit increasingly non-linear responses that complex output current responses that are not adequately described by output slew and delay. For example, reduced device dimensions generally result in faster circuits, which in turn requires greater modeling accuracy. To provide this enhanced modeling accuracy, the nuances of device behavior (in particular output current behavior) must be properly captured.
Therefore, advanced EDA tools have begun to incorporate output current-based schema (rather than output voltage-based schema) for cell modeling. In particular, modern driver models for gate-level delay calculations with parasitics make use of current-versus-time (I(t)) and current-versus-voltage (I(V)) characteristics obtained from current and voltage waveforms in time, Iout(t) and Vout(t) respectively. This data is measured over sets of varying input slew and output capacitance values. By interpolating the output current data along these sets of precharacterization input slew and output capacitance values, model output signals can be derived for given sets of actual input slew and output capacitance values.
A major issue in the customer adoption of current-based driver models is the amount of data-storage required. Precharacterization output current signals (generated either via actual device measurements or via mathematical (e.g., HSPICE) simulations) are converted into piecewise linear representations consisting of sets of current values indexed by sets of corresponding time values. Each pair of current and time values represents a point on a precharacterization output current curve. For example, Table 1 depicts an exemplary cell library entry for driver model 210A (described with respect to FIG. 3).
TABLE 1SET1SET2(SinpA,(SinpB,TimeCoutA)CoutA)Drivert1IoutA1IoutB1Modelt2IoutA2IoutB2210At3IoutA3IoutB3t4IoutA4IoutB4t5IoutA5IoutB5t6IoutA6IoutB6t7IoutA7IoutB7t8IoutA8IoutB8t9IoutA9IoutB9t10IoutA10IoutB10Table 1 includes sets of output current data for two output current signals S_OUTA and S_OUTB. Output current signals S_OUTA and S_OUTB are associated with different input slews SinpA and SinpB, respectively, but are associated with the same output capacitance CoutA. The signal data for output current signal S_OUTA includes output current values IoutA1 through IoutA10, which are indexed by time values t1 through t10, respectively. Similarly, the signal data for output current signal S_OUTB includes output current values IoutB1 through IoutB10, which are indexed by time values t1 through t10, respectively. Note that some conventional driver models store output voltage over time, from which output current values can be calculated using the equation Iout=Cout*dVout/dt.
As evident from Table 1, the larger the number of time values (and corresponding output current values) used to generate the data for an output signal, the more accurate the piecewise linear representation of the actual output signal becomes. At the same time, increasing the number of data points also increases the data storage and computational requirements associated with the driver model. Therefore, generation of a piecewise linear representation of an output current signal involves balancing model accuracy with model size.
Furthermore, due to the nature of output current response curves indexed by input slew and output capacitance, standard interpolation along either input slew or output capacitance can sometimes provide inaccurate results. For example, FIG. 4 shows a graph of sample precharacterization output current signals S_OUT1 and S_OUT2, which are associated with the same output capacitance value (5 fF) but different input slew values (100 ps and 200 ps, respectively).
Also depicted in FIG. 4 is a graph of an interpolated output current signal S_OUT-STD (represented by the dashed line) associated with the same output capacitance value (5 fF) as signals S_OUTA1 and S_OUTA2 but a different input slew value (150 ps). Interpolated output current signal S_OUT-STD is generated by directly interpolating between signals S_OUT1 and S_OUT2 according to input slew (i.e., because the input slew associated with interpolated signal S_OUT-STD is halfway between the input slews associated with precharacterization signals S_OUTA1 and S_OUTA2, the value of interpolated signal S_OUT-STD at any given time is halfway between the values of precharacterization signals S_OUTA1 and S_OUTA2.
Unfortunately, interpolated signal S_OUT-STD is not an accurate representation of the actual output signal associated with an input slew of 150 ps. As indicated by the profiles of precharacterization signals S_OUTA1 and S_OUTA2, the profile of a signal associated with an input slew of 150 ps should exhibit a single peak located between the peaks of signals S_OUTA1 and S_OUTA2 (such as described below with respect to FIG. 6A). However, due to the nature of direct interpolation, interpolated signal S_OUT-STD only exhibits peaks that are aligned with the peaks of signals S_OUTA1 and S_OUTA2, rather than a peak between those of signals S_OUTA1 and S_OUTA2.
Accordingly, it is desirable to provide a system and method for generating an output current-based driver model that minimizes storage requirements while maintaining model accuracy.